
%% bare_conf.tex
%% V1.3
%% 2007/01/11
%% by Michael Shell
%% See:
%% http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.7 or later) with an IEEE conference paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/tex-archive/macros/latex/contrib/IEEEtran/
%% and
%% http://www.ieee.org/

%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE! 
%% User assumes all risk.
%% In no event shall IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including  **
%% ** renaming them and changing author support contact information. **
%%
%% File list of work: IEEEtran.cls, IEEEtran_HOWTO.pdf, bare_adv.tex,
%%                    bare_conf.tex, bare_jrnl.tex, bare_jrnl_compsoc.tex
%%*************************************************************************

% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. IEEE's font choices can trigger bugs that do  ***
% *** not appear when using other class files.                            ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/



% Note that the a4paper option is mainly intended so that authors in
% countries using A4 can easily print to A4 and see how their papers will
% look in print - the typesetting of the document will not typically be
% affected with changes in paper size (but the bottom and side margins will).
% Use the testflow package mentioned above to verify correct handling of
% both paper sizes by the user's LaTeX system.
%
% Also note that the "draftcls" or "draftclsnofoot", not "draft", option
% should be used if it is desired that the figures are to be displayed in
% draft mode.
%

\documentclass[10pt, conference, compsocconf]{IEEEtran}
\usepackage{ifpdf}
\usepackage{multicol}

\usepackage{algorithmic}
\usepackage{subfloat}
\usepackage{algorithm}
\usepackage{textcomp}
\usepackage{listings}
\usepackage{graphicx}
\pagenumbering{roman}
\usepackage[table]{xcolor}
\usepackage[font=footnotesize]{subfig}

 
% Add the compsocconf option for Computer Society conferences.
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[conference]{../sty/IEEEtran}





% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/tex-archive/macros/latex/contrib/oberdiek/
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.






% *** CITATION PACKAGES ***
%
%\usepackage{cite}
% cite.sty was written by Donald Arseneau
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 4.0 (2003-05-27) and later if using hyperref.sty. cite.sty does
% not currently provide for hyperlinked citations.
% The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/cite/
% The documentation is contained in the cite.sty file itself.






% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
  % \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.pdirewall,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  % \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by David Carlisle and Sebastian Rahtz. It is
% required if you want graphics, photos, etc. graphicx.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at: 
% http://www.ctan.org/tex-archive/macros/latex/required/graphics/
% Another good source of documentation is "Using Imported Graphics in
% LaTeX2e" by Keith Reckdahl which can be found as epslatex.ps or
% epslatex.pdf at: http://www.ctan.org/tex-archive/info/
%
% latex, and pdflatex in dvi mode, support graphics in encapsulated
% postscript (.eps) format. pdflatex in pdf mode supports graphics
% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
% not a bitmapped formats (.jpeg, .png). IEEE frowns on bitmapped formats
% which can result in "jaggedy"/blurry rendering of lines and letters as
% well as large increases in file sizes.
%
% You can find documentation about the pdfTeX application at:
% http://www.tug.org/applications/pdftex





% *** MATH PACKAGES ***
%
\usepackage[cmex10]{amsmath}
% A popular package from the American Mathematical Society that provides
% many useful and powerful commands for dealing with mathematics. If using
% it, be sure to load this package with the cmex10 option to ensure that
% only type 1 fonts will utilized at all point sizes. Without this option,
% it is possible that some math symbols, particularly those within
% footnotes, will be rendered in bitmap form which will result in a
% document that can not be IEEE Xplore compliant!
%
% Also, note that the amsmath package sets \interdisplaylinepenalty to 10000
% thus preventing page breaks from occurring within multiline equations. Use:
%\interdisplaylinepenalty=2500
% after loading amsmath to restore such page breaks as IEEEtran.cls normally
% does. amsmath.sty is already installed on most LaTeX systems. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/amslatex/math/





% *** SPECIALIZED LIST PACKAGES ***
%
%\usepackage{algorithmic}
% algorithmic.sty was written by Peter Williams and Rogerio Brito.
% This package provides an algorithmic environment fo describing algorithms.
% You can use the algorithmic environment in-text or within a figure
% environment to provide for a floating algorithm. Do NOT use the algorithm
% floating environment provided by algorithm.sty (by the same authors) or
% algorithm2e.sty (by Christophe Fiorio) as IEEE does not use dedicated
% algorithm float types and packages that provide these will not provide
% correct IEEE style captions. The latest version and documentation of
% algorithmic.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithms/
% There is also a support site at:
% http://algorithms.berlios.de/index.html
% Also of interest may be the (relatively newer and more customizable)
% algorithmicx.sty package by Szasz Janos:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithmicx/




% *** ALIGNMENT PACKAGES ***
%
%\usepackage{array}
% Frank Mittelbach's and David Carlisle's array.sty patches and improves
% the standard LaTeX2e array and tabular environments to provide better
% appearance and additional user controls. As the default LaTeX2e table
% generation code is lacking to the point of almost being broken with
% respect to the quality of the end results, all users are strongly
% advised to use an enhanced (at the very least that provided by array.sty)
% set of table tools. array.sty is already installed on most systems. The
% latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/tools/


%\usepackage{mdwmath}
%\usepackage{mdwtab}
% Also highly recommended is Mark Wooding's extremely powerful MDW tools,
% especially mdwmath.sty and mdwtab.sty which are used to format equations
% and tables, respectively. The MDWtools set is already installed on most
% LaTeX systems. The lastest version and documentation is available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/mdwtools/


% IEEEtran contains the IEEEeqnarray family of commands that can be used to
% generate multiline equations as well as matrices, tables, etc., of high
% quality.


%\usepackage{eqparbox}
% Also of notable interest is Scott Pakin's eqparbox package for creating
% (automatically sized) equal width boxes - aka "natural width parboxes".
% Available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/eqparbox/





% *** SUBFIGURE PACKAGES ***
%\usepackage[tight,footnotesize]{subfigure}
% subfigure.sty was written by Steven Douglas Cochran. This package makes it
% easy to put subfigures in your figures. e.g., "Figure 1a and 1b". For IEEE
% work, it is a good idea to load it with the tight package option to reduce
% the amount of white space around the subfigures. subfigure.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at:
% http://www.ctan.org/tex-archive/obsolete/macros/latex/contrib/subfigure/
% subfigure.sty has been superceeded by subfig.sty.



%\usepackage[caption=false]{caption}
%\usepackage[font=footnotesize]{subfig}
% subfig.sty, also written by Steven Douglas Cochran, is the modern
% replacement for subfigure.sty. However, subfig.sty requires and
% automatically loads Axel Sommerfeldt's caption.sty which will override
% IEEEtran.cls handling of captions and this will result in nonIEEE style
% figure/table captions. To prevent this problem, be sure and preload
% caption.sty with its "caption=false" package option. This is will preserve
% IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later 
% (recommended due to many improvements over 1.2) of subfig.sty supports
% the caption=false option directly:
%\usepackage[caption=false,font=footnotesize]{subfig}
%
% The latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/subfig/
% The latest version and documentation of caption.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/caption/




% *** FLOAT PACKAGES ***
%
%\usepackage{fixltx2e}
% fixltx2e, the successor to the earlier fix2col.sty, was written by
% Frank Mittelbach and David Carlisle. This package corrects a few problems
% in the LaTeX2e kernel, the most notable of which is that in current
% LaTeX2e releases, the ordering of single and double column floats is not
% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
% single column figure to be placed prior to an earlier double column
% figure. The latest version and documentation can be found at:
% http://www.ctan.org/tex-archive/macros/latex/base/



%\usepackage{stfloats}
% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
% the ability to do double column floats at the bottom of the page as well
% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
% LaTeX2e). It also provides a command:
%\fnbelowfloat
% to enable the placement of footnotes below bottom floats (the standard
% LaTeX2e kernel puts them above bottom floats). This is an invasive package
% which rewrites many portions of the LaTeX2e float routines. It may not work
% with other packages that modify the LaTeX2e float routines. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/sttools/
% Documentation is contained in the stfloats.sty comments as well as in the
% presfull.pdf file. Do not use the stfloats baselinefloat ability as IEEE
% does not allow \baselineskip to stretch. Authors submitting work to the
% IEEE should note that IEEE rarely uses double column equations and
% that authors should try to avoid such use. Do not be tempted to use the
% cuted.sty or midfloat.sty packages (also by Sigitas Tolusis) as IEEE does
% not format its papers in such ways.





% *** PDF, URL AND HYPERLINK PACKAGES ***
%
%\usepackage{url}
% url.sty was written by Donald Arseneau. It provides better support for
% handling and breaking URLs. url.sty is already installed on most LaTeX
% systems. The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/misc/
% Read the url.sty source comments for usage information. Basically,
% \url{my_url_here}.





% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}


\begin{document}
%
% paper title
% can use linebreaks \\ within to get better formatting as desired
\title{Automatic Refactoring of Security-Policy-Based Software Systems for Performance Improvement}


% author names and affiliations
% use a multiple column layout for up to two different
% affiliations

\author{\IEEEauthorblockN{Donia El Kateb, Tejeddine Mouelhi, Yves Le Traon}
\IEEEauthorblockA{Donia El Kateb, Tejeddine Mouelhi, Yves Le Traon\\
line 2: University of Luxembourg\\
line 3: City, Country\\
line 4: Email:  \{donia.elkateb, tejeddine.mouelhi, yves.letraon\}@uni.lu}
\and
\IEEEauthorblockN{JeeHyun Hwang, Tao Xie}
\IEEEauthorblockA{Dept. of Computer Science, 
North Carolina State University, 
Raleigh, NC 27695, U.S.A\\\\
line 2: name of organization, acronyms acceptable\\
line 3: City, Country\\
line 4: Email: \{jhwang4@ncsu.edu,xie@csc.ncsu.edu\}}
}
\author{
Donia El Kateb, Tejeddine Mouelhi, Yves Le Traon\\

 \{donia.elkateb, tejeddine.mouelhi, yves.letraon\}@uni.lu\\\\
% For a paper whose authors are all at the same institution,
% omit the following lines up until the closing ``}''.
% Additional authors and addresses can be added with ``\and'',
% just like the second author.
JeeHyun Hwang, Tao Xie\\
Dept. of Computer Science, 
North Carolina State University, 
Raleigh, NC 27695, U.S.A\\
\{jhwang4@ncsu.edu,xie@csc.ncsu.edu\}\\
}
% conference papers do not typically use \thanks and this command
% is locked out in conference mode. If really needed, such as for
% the acknowledgment of grants, issue a \IEEEoverridecommandlockouts
% after \documentclass
% for over three affiliations, or if they all won't fit within the width
% of the page, use this alternative format:
% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle
\pagestyle{plain} % No headers, just page numbers
\pagenumbering{arabic} % Roman numerals
\setcounter{page}{1}

\begin{abstract}
Modern access control architectures tend to separate the business logic from access control policy specification for the sake of authorizations 
manageability. Request evaluation is processed by a Policy Decision Point (PDP) that encapsulates the access control policy and interacts with the
 business logic through Policy Enforcement Points (PEPs). 
Such architecture may engender a performance bottleneck due to the number of rules that have to be evaluated by a single PDP.
To address the issue, we propose an automated refactoring approach to optimize the process of policy-based decision-making by splitting the
 single PDP into smaller decision points in synergy with the business logic. We conducted studies on XACML (eXtensible Access Control Markup 
Language), to identify the best PDP splitting configuration. Our evaluation results show that our approach reduces the request evaluation time by up to 9 times
 and preserves the architectural model.

\end{abstract}

\begin{IEEEkeywords}
Security policy, performances, access control, architecture, XACML, Optimization.
\end{IEEEkeywords}


% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle
\section{Introduction} 

%- Access control security vs compromise performance
%- Define acces control in xacml setting (subject action resource)
%- Situation of our approach Context evaluations previous approach + contribution dimensions
%- Main idea + open reserach issues
%-Structure


Should developers sacrifice performance while enforcing security requirements (e.g., access control) in applications? 
IT experts would answer ``Absolutely not, in today's competitive market, this would impact the business''. 
Access control mechanisms often manage a large number of resources for organizations with sophisticated structures and work flow.
Access control mechanisms are governed by access control policies (i.e., policies in short)~\cite{policymanagement}, which
define rules to regulate access control rights \cite{acp} (e.g., determine whether a subject can access to a resource).
While access control mechanisms are important to enhance security and privacy, performance issue is crucial for adoption of access control mechanisms in real-world information systems \cite{Xengine}.
Since rules in a policy are evaluated by requests of subjects access on resources at runtime,
a policy with a large number of rules often requires high evaluation time, which causes performance bottlenecks and impacts service availability.

%In addition, fine-grained access control mechanisms must both comply with three access control architectural requirements \cite{scalabilityaccesscontrol}: 
%scalability, transparency, and optimization of request evaluation.


In practice, access control architectures often follow a popular architectural concept, which separates a policy enforcement point (PEP) from a policy decision point (PDP) \cite{separation}.
More specifically, the PEP is located inside the application (i.e., business logic of the system) and formulates requests.
The PDP encapsulates the policy. The PDP then receives requests from the PEP and returns evaluation responses (e.g., grant or deny) by evaluating these requests against rules in the policy.
This architecture enables to facilitate manage access rights in a fine grained way since this architecture
decouples the business logic from access control decision logic, which can be standardized. In this architecture,
the policy is centralized in one point, the PDP. Centralization of the PDP offers advantages such as 
facilitating manage and maintain the policy, which is encapsulated in a single PDP. However, such centralization can be a pitfall for degrading 
performance since the PDP manages all of access rights to be evaluated by requests issued by PEPs.


To address the performance issue, we propose an access control policy refactoring mechanism that reduces 
the request evaluation time and enables to preserve the synergy property in the access control model. In this paper, we define this property as the cardinality based feature that 
characterizes the association between the the PEPs and the PDP. This association impacts the way PEPs interact with the PDP. We assume that this property holds if the association 
between the PEPs and the PDPs enables to map each PEP, once triggered, to a single PDP. On the other hand, a PDP can be mapped to several PEPs. Therefore, this property holds for the traditional 
architecture where there is a unique PDP. 

In our approach, we consider policy-based software systems, which 
enforce access control policies specified in eXtensible Access Control Markup Language (XACML) \cite{sunxacml}. XACML is a popularly used xml-based language to specify rules in a policy. A rule specifies which subjects can take which actions on resources in which condition.
%AS a standard policy specification language, XACML has emerged as a pressing need, for expressing access control security policies in heteregenous environments.
We propose an automated approach for optimizing the process of decision
 making in XACML request evaluation that combines two facets: (1) performance optimization criteria to split the PDP into smaller decision points,
 (2) architectural model preservation to keep the synergy between PDP and PEPs.
The performance optimization facet of the approach lies in transforming the single PDP into smaller PDPs,
 through an automated refactoring of a global access control policy (i.e., a policy governing all of access rights in application).
This refactoring involves grouping rules in the global policy into several subsets based on splitting criteria. 

More specifically, we propose a set of splitting criteria to refactor the global policy into smaller policies.
A splitting criterion selects and groups the access rules of the overall PDP into specific PDPs. 
Each criterion specific PDP encapsulates a sub-policy that represents a set of rules that share a combination 
of attribute elements (Subject, Action, and/or Resource).
Our approach takes as input a splitting criterion and a original global 
policy and returns a set of corresponding sub-policies. Given a set of requests, we then compare evaluation
time of the requests against the original policy and a set of sub-polices based on the proposed splitting criteria. 

The architectural model preservation facet aims at selecting the splitting criteria that do not alter the initial architectural
 model and that preserve the synergy property of the access control model. The proposed refactoring keeps the separation of the PDP and 
the PEPs and focuses on establishing an appropriate mapping 
between them. The best splitting criteria must thus both improve performances and comply to our architectural model: the relationship must be maintained, 
linking each PEP to a given PDP. When refactoring the system, each PEP in our system 
can be mapped to a set of rules that will be relevant when evaluating the 
request. We automate this refactoring process.
Our evaluation results show that our approach enables decision making process to be nine times faster than 
a scenario with regards to only a single global access control policy.

In our previous work \cite{Xengine}, we addressed performance issues in access control policy evaluation by using 
a decision engine ``XEngine'' that outperforms Sun PDP \cite{oasis} implementation. XEngine transforms an original XACML policy
into its corresponding policy in a tree format by mapping of attribute values with numerical values.
Our contribution in this paper goes in the same research direction as it aims to reduce the request evaluation time. However, in this paper, we 
do not provide a decision engine to evaluate requests effectively. We propose a refactoring process that impacts the policy format.
Our evaluation results show that evaluation time is reduced up to nine times with splitted policies if compared to its original global policy.
Our evaluation results show that we have a considerable performance improvement, if the policies resulting from our refactoring process are evaluated 
with XEngine rather than Sun PDP.


%The evaluation results show that we have a considerable performance improvement, if the policies resulting from our refactoring process are evaluated 
%with XEngine rather than Sun PDP.

This paper makes the following three main contributions:
\begin{itemize}
	\item We develop an approach that refactors a single global policy into smaller policies to improve performance in terms of policy evaluation. 
	\item We propose a set of splitting criteria to help refactor a policy in a systematic way. The splitting criteria does not alter the initial architectural
 model and preserves the synergy property of the access control model
	\item We conduct evaluations on real-life policies subjects to measure performance improvement
  using our approach. We compare our approach with an approach based on the global policy in terms of
effectiveness. Our approach achieves more than nine times faster than that of the approach based on the global policy in terms of evaluation time.		 
\end{itemize}



The remainder of this paper is organized as follows: Section~\ref{sec:context} introduces access control policy flow models in XACML, 
and access
 policy architecture model.
Section {sec:approach} presents our adopted strategy and 
Section {sec:experiment} presents evaluation results and discusses the effectiveness of our approach. Section~\ref{sec:related}
 discusses related work. 
Section  concludes this paper and discuses future research directions.
\section{Context/Problem Statement}
In this section, we start by presenting the access control data flow model, which depicts the relationships between the PDP and the PEPs,
further, we present the performance issues in XACML access control policies and the synergy property that we aim to preserve in our automated process 
of refactoring.

\subsection{Access Control Data Flow Model}

Most access control scenarios involve an access control policy which is modeled, analyzed and implemented as a separate component
 encapsulated in a PDP,
 which interacts with the business logic through the PEP that may receive access control requests. 
Like illustrated in Figure \ref{pep-pdp}, the PEP in turn calls the PDP to retrieve an authorization decision based on which it will
 grant or deny access. The authorization decision is made through the evaluation of the different rules in the access control policy. 
Subsequently, an authorization decision is returned to the PEP.
This separation in existing access control systems simplifies policy management across many heteregenous systems and enables to avoid
 potential risks that can arise from incorrect policy implementation, when scattered throughout the different applications embedded
 in the business logic.
In this paper, we focus on access control decision making for XACML based authorization policies.
 XACML \cite{sunxacml} is an open standard that defines a syntax for access control policies specification.

\begin{figure}[!h]
\begin{center}
\includegraphics[width=9cm, height=8cm]{business-logic.pdf}
\caption{Access Control Request Processing}
\label{pep-pdp}
\end{center}
\end{figure}
\subsection{XACML Access Control Policies and Performance Issues}
%\begin{figure}[!h]
%\begin{center}
%\includegraphics[width=12cm, height=10cm]{optimisation.jpeg}
%\caption{\label{XACML Architecture}XACML Architecture}
%\end{center}
%\end{figure}
In the XACML paradigm, a policy set element is defined as a sequence of policies, a combining algorithm and
 a target. A single policy is expressed through a target, a set of rules and a rule combining algorithm. 
The target defines a set of resources, subjects, and actions to which a rule is intended to apply. A rule set is a sequence of rules. Each rule is composed of a 
target, a condition, and an effect. The condition is a boolean expression that specifies the restrictions on the elements in the target, 
the effect is either permit or deny. 
The combining algorithm represents a method of combining multiple decisions into a single decision, and thus is used to deduce the
 final decision, in case of potential conflicting decisions that can result, for example, from the evaluation of two 
rules which are applicable to the same request and which provide different decisions.


If we take the example of permit-overrides algorithm, 
the policy evaluation engenders the following decisions: 
\begin{itemize}
\item Permit if any rule in the policy, matching the request, is evaluated to permit.
\item Deny if all the rules evaluate to deny.
\item NotApplicable if no rule is applicable.
\end{itemize}

Figure \ref{figur1} shows a simple XACML policy that denies the subject Bob to borrow a book.
\fontsize{5}{5}
\begin{figure}[!h]
\begin{center}
\includegraphics[width=8.6cm]{xacml.pdf}
\caption{XACML Policy Example}
\label{figur1}
\end{center}
\end{figure}

The XACML request encapsulates attributes that define who is making the request, what protected resource in \normalsize the system is being requested and
 what operation or action is to be performed on that resource. A request which satisfies both the rule target and the rule condition has a response 
that is sent with the decision specified by the effect element in the
 applicable rule. If a request does not satisfy both the target and the condition, the response yields ``NotApplicable''.
\\As standard, XACML enables administrators to externalize access control policies for the sake of interoperability since access control policies
 can be designed 
for any underlying programming language and for any supporting platform, its flexibility permits to meet access control policies requirements so
 that new requirements
 are supported. 
%\centering
%\figure[DREF metamodel\label{fig:drefMM}]
%        {\includegraphics[width=0.5\textwidth]{figure/drefMM}}
%\figure[SETER Process: Security Testing for Resilient Systems 
%\label{fig:seter}] {\includegraphics[width=0.49\textwidth]{figure/seter}}
%\caption{DREF and SETER: Conceptual and Operational Frameworks for evaluating resilient systems}
%\end{figure*}
However the increasing complexity of organizations in term of structure, relationships, activities and access control requirements has impacted 
access control policies design. This has led to deal with access control policies where the number of rules, that depicts the associations between resources, 
entities and actions in a given access control policy, is huge. Moreover, the policy is usually centralized in a single point PDP which 
has to manage multiple access control requests.
These observations should raise performance concerns related to request evaluation time for XACML access control policies. 
Performance bottlenecks can degrade the system efficiency which may slow down the overall business processes. 
Considering XACML request evaluation, many factors may lead to reduce XACML requests evaluation performance. Due to space limit, 
we only mention the following factors:

\begin{itemize}
\item An XACML policy may contain several attributes that constitute descriptive information about the target elements, the retrieval of
 varying size of attributes values for each request within XML elements in a request evaluation process may engender a performance bottleneck.
\item A PolicySet includes a set of policies, the effect of the whole
PolicySet is determined by combining the effects of the policies according to a combining algorithm, the computation of resulting effect 
from policies is also considered as a potential evaluation time latency.

\item Conditions evaluation in XACML rules may slow the decision making process since these conditions can be so complex because they can 
be built from an arbitary nesting of non-boolean functions and attributes. 
\end{itemize}

\subsection{Preserving The Access Control Architectural Model}
Managing access control policies is one of the most challenging issues faced by organizations. 
Frequent changes in access control systems may be required to meet business needs. An access control system has to handle some specific 
requirements like role swap when employees are given temporary assignments, changes in the policies and procedures, 
new assets, users and job positions in the organization.

All these facts make access control architectures very difficult to manage, and plead in favor of a 
simple access control architecture that can easily handle evolvability in access control systems. 
In the line of reasoning about performance, we propose to maintain the simplicity of the initial access control architecture whose model 
is presented in Figure \ref{model}.

In this model, a set of business processes, that comply to users needs, are encapsulated in a given business logic which is enforced 
by multiple PEPs. Conceptually, the decision is decoupled from the enforcement and involves a decision making process in which each PEP interacts 
with one PDP, thus a single XACML policy is evaluated to provide the suitable response for an access control request provided by a PEP. 

Considering a single XACML policy file for each initiating PEP enables to:
\begin{itemize}
 \item Ease policies management.
\item  Maintain a simple architecture in which the suitable decision point is triggered by a PEP in a given request.
\end{itemize}



For this sake, we propose to preserve the cardinality based property between the PEP and the PDP in the system.
 In such configuration, a PEP triggers a single PDP that manages a single policy file. We assume that adopting a strategy to increase request evaluation performance should preserve this property 
which holds already for the initial architecture. The next section describes our approach and gives an insight of the process supporting it.


\begin{figure}[!h]
\begin{center}
\includegraphics[height=4.5cm,width=8cm]{model.pdf}
\caption{The Access Control Model}
\label{model}
\end{center}
\end{figure}

\section{Approach}

%\section{OUR APPROACH TO OPTIMIZING DECISION MAKING IN XACML}
 
In this section, we describe the PDP splitting approach which automates the refactoring of the global access control policy. The objective is to make 
the request evaluation process more performant, while preserving system functionality and architectural model. 
Since a decision making process involves the evaluation of all the rules in the global policy, we propose to reduce 
the number of rules that have to be evaluated for a given request issued by a PEP. This boils down to the idea that the policy evaluation is 
faster when there are few rules to be processed and checked to get
 the decision. Obviously, a PDP that has to check 2 rules will be much faster that a PDP that checks 200 rules. However what happens in a request 
evaluation process is that for a given access control request, some rules are evaluated in the global policy whereas some of those rules are not
 applicable to the request. Starting from this observation, we propose a scenario in which only the relevant rules for a given request will be evaluated
 in the decision making process, this scenario is based on a refactoring operation supported by our prototype tool. It automates the policy splitting 
into ``smaller'' policies based on attribute values combination. In the following, we will provide some technical details to illustrate our refactoring 
process, and show how we can select the splitting criterion that enables to preserve the architecture.
%a tradeoff between performance and access control policies management requirements like transparency and scalability.

\subsection{XACML Policy Refactoring Process}
%In \cite{clustering}, the authors decompose the global policy into a set of policies where each set gathers the subjects that share common applicable
%rules whereas in \cite{decomposition} the proposed approach involves evaluating all the boolean expressions \cite{boolean} for all the rules in the 
%policy and clustering all the rules having the same boolean expression.
%the PDP component which fetches the necessary policies and necessary attributes for decision making.

Our conceptual approach to improve the performance in the XACML decision making process focuses on reducing the request evaluation time.
We assume that this time would be reduced considerably if the PDP handles a ``smaller'' policy. We propose to transform the policy P into smaller policies 
$P_{SC_{w}}$ where each policy conforms to what we define as a Splitting Criteria SC$_{w}$.
A splitting criterion SC$_{w}$ defines the set of target elements, that can be considered to classify all the rules into sets of rules having the 
same target elements, $w$ is a weight that denotes the number of target elements that have to be considered conjointly for aggregating rules into
 an unified set based on specific target elements selection.

An XACML policy can be refactored considering one target element, in such setting a policy can be splitted into a set of policies where the 
rules have the same subject, resource, or action. Rules can also be aggregated considering two splitting criteria like $<$Subject, Action$>$ or
 $<Action, Resource>$, in this setting, a policy will be transformed into a set of ``smaller'' policies where rules in the resulting policies have the same 
couple of target elements. 
We can go further in our grouping strategy by creating $P_{SC_{w}}$ whose 
rules match a specific triplet of resource, action and subject. Table 1 shows all the combination of the splitting criteria according to the weight of 
target elements.

\begin{table}[h!]
\centering
\setlength{\extrarowheight}{6 pt}
\begin{tabular}{|l|c|}   
\hline  \rowcolor{black} 
 \bf
\textcolor  {white}{Splitting Criteria}& \bf \textcolor{white}{Possible Values}\\ \hline
 
$SC_{1}$& {$<Subject>, <Resource>, <Action>$}\\ \hline
\scriptsize 
$SC_{2}$& {$<Subject,Action>, <Subject,Resource>$}\\&\scriptsize{$<Resource,Action>$}\\  \hline
\scriptsize  
$SC_{3}$& {$<Subject,Resource,Action>$}\\ \hline
\end{tabular}
\caption{Splitting Criteria}\label{table1}\end{table}

In this setting, we put forward an access control architecture built with multiple (PDPs), where each PDP enforces
a policy that complies to a certain splitting criterion. A mapping table data structure is used to define the 
mapping between potential request target elements and corresponding smaller policies $P_{SC_{w}}$.
We propose a schema in which a given PEP interacts with a dispatcher that receives the PEP's request, fetches the mapping table and extracts 
the suitable PDP that has to provide a response for given request. Figure \ref{decomposition}.a gives an overview of this architecture in the 
case where SC$_{1}$=$<$subject$>$ is chosen as a splitting criterion. In this scenario, the PEP formulates the request, and forwards it to an intermediary component, ``the dispatcher'', that receives the XACML request and fetches 
the subject's request attributes. The PDPs that are relevant for the subjects attributes are localized through the mapping table, and used to provide the 
XACML response to the initiating PEP. 

\begin{figure}[!h]
\begin{center}
\includegraphics[width=9cm]{pep-pdp}
\caption{Request processing: (a)-PDP splitting based on target elements: SC$_{1}$=$<$subject$>$/(b)-
PDP splitting based on system functions}
\label{decomposition}
\end{center}
\end{figure}
%With the objective of highlighting some relevant considerations that have to be taken in the decomposition process:
\begin{large}
\end{large}

In the following, we explore the prospects of our refactoring process through some technical examples that take into 
consideration XACML language features:
\begin{itemize}
\item The XACML policy 1 presented in Figure \ref{xacml-decomposition} is a simple XACML policy whose target elements
 defined for the global XACML policy are \normalsize $<AnyResource>$, $<AnySubject>$, $<AnyAction>$, thus the global policy is applicable 
to any subjects, any resources and any actions.
The refactoring of this policy according to the splitting criterion 
SC$_{1}=<$Subject$>$ consists in splitting the XACML policy into the sub-policies 2 and 3 where each sub-policy groups the rules 
that are relevant for each subject (Alice and Bob in the example). 
XACML policies 2 and 3 are the two resulting policies that show how the present 
rules in the policy 1 are dispatched in XACML policies 2 and 3.

\item
In the previous example, the target element has a simple structure, however target elements 
in XACML may have a structure which is more complex, if they encapsulate target elements Match.
As stated in \cite{oasis}, $<ResourceMatch>$, $<SubjectMatch>$, $<ActionMatch>$ 
elements define a set of target elements related entities that has to match at the decision level with the context element in 
an access control request. If a structure of target element match is used, it encapsulates the following elements:

\begin{itemize}
\item A MatchId element which defines a matching function, like ``string-equal'' in the example of figure 
\ref{multi-attributes}, besides an attribute value.
\item An AttributeDesignator that identifies the attributes values of the target element.
\end{itemize}

In case, we have a structure of target elements that conforms to the structure shown in Figure \ref{multi-attributes},
two target elements, are equals if they have respectively equal sets of MatchId, attribute values, and AttributeDesignators. 
In case, there is a difference in one of the mentioned sets the two target elements could be considered as different target elements 
and thus dispatched into different policies in a refactoring process.


\begin{figure}[!h]
\centering
\includegraphics[width=9cm]{exemple1}
\caption{XACML policy refactoring process example: $SC_{1}=<Subject>$ }
\label{xacml-decomposition}
\end{figure}

\end{itemize}
\begin{figure}[!h]
\begin{center}
\includegraphics[width=8cm, height=3.5cm]{xacml-match}
\caption{Multi-attributes Target Element}
\label{multi-attributes}
\end{center}
\end{figure}

\subsection{Architecture Model Preservation: PEP-PDP Synergy}
We consider the different splitting criteria that we have identified in the previous section and we propose to select the splitting 
criteria that enable to preserve the synergy property in the access control architecture.
The selected splitting criteria should enable to have multiple policies encapsulated in several PDPs 
where each PDP is mapped to a single PEP.
A PEP-PDP mapping is observable through the code at application level. In fact, a deep analysis of the PEPs and 
the corresponding triggered rules, enables to explicitly describe this mapping. At the application level, every PEP is mapped to a 
service
 implementation through a system method call that triggers a decision making process by activating some specific rules in a single 
PDP.

The code below is taken from \cite{legacy}, this code excerpt shows an example of a PEP which is implemented by the method 
checkSecurity, this method calls the class SecurityPolicyService that initiates the PDP component.
\begin{algorithmic}
\begin{algorithm}[!h]
%\caption{System security function that describes a PEP enforcement}
   \STATE public void borrowBook(User user, Book book)
   \STATE throws SecuritPolicyViolationException {
   \STATE   // call to the security service
\STATE \hspace{0.5cm} \textbf{ServiceUtils.checkSecurity(user,
\STATE LibrarySecurityModel.BORROWBOOK\_METHOD,
\STATE LibrarySecurityModel.BOOK\_VIEW);}
\STATE ContextManager.getTemporalContext());
    \STATE  // call to business objects
    \STATE  // borrow the book for the user
\STATE \hspace{0.5cm} book.execute(Book.BORROW, user);
\STATE      // call the dao class to update the DB
\STATE \hspace{0.5cm} bookDAO.insertBorrow(userDTO, bookDTO);}
\end{algorithm}
\end{algorithmic}

An analysis of this code reflects that this function will trigger exclusively all the rules organized by the couple (Action, Resource) for 
the subject given as input parameter. This is due to the call of the following methods: LibrarySecurityModel.BORROWBOOK\_METHOD and 
LibrarySecurityModel.BOOK\_VIEW.

%%%%%
Conceptually, we propose to transform the global policy into subsets of rules where each subset can be mapped to a PEP.
In this setting, each single request initiated by a specific PEP will have its corresponding evaluating PDP conforming to the PEP-PDP matching. 
This implies that the different method calls initiated by PEPs are identified at the code level at the decision making time and mapped to their 
corresponding PDPs. A mapping table is used to establish the link between each PEP implementation and the corresponding rules 
encapsulated in a given PDP. A general schema for this approach is presented in Figure \ref{decomposition}.b.

Figure \ref{synergy} synthesizes the concept of synergy between PEPs and corresponding PDPs. In the worse case, splitting the initial PDP into multi-PDPs may lead to a non-synergic system: a PEP may send its requests to several PDPs. The PDP, which receives a request is only known at runtime. Such a resulting architecture breaks the PEP-PDP synergy and the conceptual 
simplicity of the initial architectural model. The splitting criteria which lead to such a non-synergic architecture is not a valid refactoring: 
the complexity induced by the splitting, makes the maintenance and evolution of the system more difficult to manage.
In the best case, the refactoring preserves the simplicity of the initial architecture, by keeping a many-to-one association from PEPs to PDPs. A given request evaluation 
triggered by one PEP will always be handled by the same PDP. Operationally, the request evaluation process will involve 
one XACML policy file. In this case, the refactoring is valid, since its does not impact the conceptual architectural model of the system.

\begin{figure}[!h]
\begin{center}
\includegraphics[width=9cm]{synergy}
\caption{Synergic system / Non synergic system}
\label{synergy}
\end{center}
\end{figure}

Depending on the system architecture, establishing this mapping may require to identify all the enforcements points in an application, and to 
track the different method calls 
triggered from these specific enforcement calls to map them to the relevant access control rules.  
In this work, we analyze the best splitting criteria in our empirical studies, for these empirical studies, we know in advance our different PEPs and their corresponding relevant rules. 
%We propose to identify automatically the different PEPs in a future work, however for this work, we can identify easily the different PEPs as we know in
% advance that system functions are implemented through the consideration of (Resource, Action) target elements thus a policy refactoring according 
%to system function is assimilated to policy refactoring according to the splitting criteria SC$_{1}=<$Action,Resource$>$. 

Our empirical results, presented in section~\ref{sec:experiment}, have shown that adopting a policy refactoring based on system functions, as a refactoring strategy, enables to reduce the decision making time. 
%Our empirical results have constantly shown that adopting a policy refactoring based on system functions, as a refactoring strategy, enables to reduce the decision making time. 
This strategy takes into consideration how the PEPs interact with the PDPs, how the rules are activated across the system, and preserve
the architectural model since we preserve the cardinality relation between PEPs and PDPs.
 
As depicted in Figure \ref{overallprocess}, the refactoring process is automated and starts by specifying and creating the XACML file which 
will be split by our tool according to a specified SC that can be chosen by an access control stakeholder. Afterwards, the policies are included in the 
framework that supports our approach. For every change in the access control policy, the initial policy is updated and 
split again in order to be included again in the framework.

\begin{figure}[!h]

\begin{center}
\includegraphics[width=8.5cm, height=8cm]{Overall-process}
\caption{Overview of the process of defining and deploying Access Control policies}
\label{overallprocess}
\end{center}
\end{figure} 
From a point of view of the system administration, maintaining and updating the access control policies is completely a standalone and simple
 process. The input is usually a centralized XACML policy. This input remains the same than before the access control performance issue is tackled.
Our process is transparent in the sense that it does not impact the existing functional aspects of the control access management system, 
for system administrators, who have to adapt the system security policy over time and have to manage various dimensions of access control 
systems such as scalability and maintainability.

\section{Empirical results}
To measure the efficiency of our approach, we conducted two empirical studies. The first, takes into consideration the whole system 
(PEPs and PDPs) and evaluates the performance improvement, in decision making process, for each splitting criterion. The request processing time, 
for each splitting criterion is also compared to the processing time of the initial policy which is non refactored, in what follows, this evaluation 
is denoted by (IA), which stands for the ``Initial Architecture''.

The second empirical study focuses only on the PDPs in isolation, to measure the gain in performance independently from system's requests. To make 
such study of PDPs in isolation, we use XEngine \cite{Xengine}. %the choice reason is detailed in corresponding section%
 The first subsection introduces our empirical studies and presents the tool that supports our approach. 
The remaining two sections present and discuss the results of the two empirical studies.  

\subsection{Empirical Studies and PolicySplitter Tool}
In this section, we present the evaluation results of the refactoring process, considering all the splitting criteria that we have identified in section 
III. The different empirical results were carried-out using the following XACML studies presented in \cite{testcase}:
\begin{itemize}	
\item LMS: The library management system offers services to manage books in a public library.
\item VMS: The virtual meeting system offers simplified web conference services. The virtual meeting server allows the organization of work meetings on 
a distributed platform.
\item ASMS (Auction Sale Management System): allows users to buy or sell items online. A seller can start an auction by submitting a description of the
item he wants to sell and a minimum price (with a start date and an ending date for the auction). Then usual bidding process can apply and people can bid 
on this auction. One of the specificities of this system is that a buyer must have enough money in his account before bidding.
\end{itemize}
We have started by a processing step, in which we have performed rules padding on the three original policies for these studies, as it would be difficult
 to observe a performance improvement results with systems containing few rules. In our evaluations, LMS policy contains 720 rules, VMS has 945 rules while ASMS implements 1760 rules. 
Our evaluations were carried out on a desktop PC, running ubuntu 9 with Core i5, 2530 Mhz processor. 
We have implemented PolicySplitter tool in Java 1.6.3, the tool takes a splitting criterion and an XACML policy as input parameters 
and provides ``smaller'' policies according to the splitting criterion provided as parameter. The tool is available for download from \cite{splitter}.
The execution time of the tool is not considered as a performance factor as it takes up to few seconds (for large policies) to perform the splitting 
according to all SCs. Moreover the refactoring process is executed only once to create a configuration that supports a selected splitting criterion. 


\subsection{Performance Improvement Results}
For the 3 evaluation studies, we have generated all the policies that conform to all the splitting criteria that we have defined in section III.
The decision Engine in our three case studies is based on Sun XACML PDP implementation \cite{sunxacml}.
To run the experiments, we use a configuartion file that maintains the list of policies used for requests evaluation. 
For the initial architecture, the configuration file contains one policy. For each splitting criteria, we have conducted functional tests to generate 
requests that trigger all the PEPs in the three evaluation studies. The test generation step is presented in \cite{transforming}.
We have repeated this process 10 times and evaluated the average execution time for all requests in each system and for each splitting criterion.


The results are shown in Figure \ref{fig:processing time}, for each splitting criterion and for the initial architecture (IA).
Note that the results are ranked from the largest processing to the smallest one. From the Figure \ref{fig:processing time}, 
for the 3 empirical studies, we can make two observations:

\begin{itemize} 
\item Compared to the initial architecture (IA), the evaluation time is considerably reduced for all splitting criteria. This is consistent, with our 
initial intuition, splitting the policy into ``smaller'' policies improves the processing time.
\item The splitting criteria \normalsize $SC=< Action, Resource>$ enables to have the best evaluation time. 
In fact, the PEPs in the 3 empirical studies, are scattered in the applications by a categorization
 that is based on $<Action, Resource>$. This plead in favor of adopting a
 splitting criteria that takes into account the PEP-PDP synergy property.
\end{itemize} 
\begin{figure*}
  \centering
  \subfloat[LMS]{\label{fig:gull}\includegraphics[width=0.33\textwidth]{LMS.pdf}}                
  \subfloat[VMS]{\label{fig:VMS}\includegraphics[width=0.33\textwidth]{VMS.pdf}}
  \subfloat[ASMS]{\label{fig:ASMS}\includegraphics[width=0.33\textwidth]{ASMS.pdf}}
  \caption{Processing Time for our 3 systems LMS, VMS and ASMS}
  \label{fig:processing time}
\end{figure*}
\begin{figure}[!h]
  \centering
\includegraphics[width=8.5cm, height=6cm]{pdpnumber.pdf}
\begin{center}
\caption{PDP Number According to Splitting Criteria}
\label{pdpnumber}
\end{center}
\end{figure} 
A refactoring process that engenders a huge number of ``smaller'' policies may lead to integrity issues. For this sake, 
we propose to evaluate PDPs number generated by each splitting criterion, to study the impact of the refactoring process on the initial policy. 
For the 3 XACML studies, we executed PoliySplitter on the 3 initial policies and we generated the number of resulting policies, in each study. 
As highlighted by Figure \ref{pdpnumber}, we notice that there are three
 categories of results: The splitting criterion $SC_{1}$ that consists in a single target element, 
leads to a small number of PDPs, the splitting criterion $SC_{2}$ produces a reasonable number of PDPs whereas $SC_{3}$ leads to a huge 
number od PDPs. The splitting criterion $SC_{2}$, thus appears as a good tradeoff in terms of performance and number of 
PDPs generated: In our evaluation studies, $SC=<Action, Resource>$ is the best criterion, both in terms of performances and low number of PDPs.

\subsubsection{Performance improvement with XEngine}
The goal of this empirical study is to show the impact of combining XEngine with our approach. In fact, XEngine improves dramatically 
the performance of the PDP \cite{Xengine}, mainly for 3 reasons:

\begin{itemize}
\item It uses a refactoring process that transforms the hierarchical structure of the XACML policy to a flat structure. 
\item It converts multiple combine algorithms to single one.
\item It lies on a tree struture that minimizes the request processing time.
\end{itemize}
We propose to use XEngine conjointly with the refactoring process presented in this work:
We have evaluated our approach in 3 settings:
\begin{itemize}
\item Considering evaluations with a non refactored policy.
\item Considering evaluations with a decision engine, based on SUN PDP, with splitted policies.  
\item Considering evaluations with a decision engine, based on XEngine rather than Sun PDP, with splitted policies.  
\end{itemize}
We have measured the processing time (in ms) for a randomly generated a set 10,000 requests. For request generation, we have used the technique presented 
int \cite{request}.
The request time processing is evaluated for LMS, VMS, ASMS.
Figure \ref{fig:processing time1} shows the results for the different splitting criteria. 
\begin{figure*}
  \centering
  \subfloat[Evaluation Time with Sun PDP]{\label{fig:gull}\includegraphics[width=0.50\textwidth]{noxengine.pdf}}                
  \subfloat[Evaluation Time with XEngine]{\label{fig:VMS}\includegraphics[width=0.50\textwidth]{xengine.pdf}}
    \caption{Processing Time for  LMS, VMS, ASMS, Pluto, Conference, Code A, Code B, Code C and Code D}
  \label{fig:processing time1}
\end{figure*}

From the figure, we can observe that, when used with a decision engine based on XEngine rather than Sun PDP, our proposed approach provides better improvement in performance. 
For the splitting criteria $SC=<Action>$, in the LMS system, the evaluation time is reduced about 12 times: from 2860 to 250 ms with XEngine. This empirical observation, 
is in favour of applying our proposed refactoring process with XEngine.

\section{Related work}
Some previous contributions have addressed access control policies performance issues, In \cite{clustering}, the authors have proposed an approach for policy evaluation based on a 
clustering algorithm that reorders rules and policies within the policy set so that the access to applicable policies is faster, their categorization is based on
 the subject target element. Their technique requires to identify the rules that are frequently used and that need to be to placed at 
the beginnig of the policy level. Our approach follows a different strategy and does not require knowing which 
rules are used the most. In addition, the rules reordering is tightly related to specific systems. If the PDP is shared between several
 systems, their approach could not applicable since the most ``used'' rules may vary between systems. \\
In \cite{decomposition}, 
the authors decomposed the global XACML policy into local policies related to collaborating parties, the local policies 
are sent to corresponding PDPs. The request evaluation is based on local policies by considering the relationships among local
 policies. In their approach, the optimization is based on storing the effect of each rule and each local policy for 
a given request. Caching decisions results is then used to optimize evaluation time for an incoming request, however the authors have 
not provided experimental results to measure the efficiency of their approach when compared to the traditional architecture.  

While the previous approaches have focused on the PDP component to optimize the request evaluation, The authors in 
\cite{XACMLstructure}, addressed this problem by analyzing rule location on XACML policy and requests at design level so that the relevant rules for the request are 
accessed faster on evaluation time. 
This work brings new dimensions to our previous work on access control \cite{Xengine} \cite{testcase} \cite{models}.
We have focused particularly in \cite{Xengine} on performance issues addressed with XACML policies evaluation and we have proposed an 
alternative solution to brute force searching based on an XACML policy conversion to a tree structure to minimize the request evaluation time. 
Our previous approach involves a refactoring process that transformes the global policy into a decision diagram converted into 
forwarding tables. In the current contribution, we introduce a new refactoring process that involves splitting the policy into smaller sub-policies. Our 
two refactoring processes can be combined to dramatically decrease the evaluation time. 

\section{Conclusion and Future Work}

In this paper, we have tackled the performance issue in access control decision making mechanism 
and we have proposed an
 automated refactoring  process  
that enables to reduce access control policies evaluation time up to 9 times.
Our approach has been applied to XACML policy language, however it can be generalized to other access control
 policy frameworks. 
To support and automate the refactoring process, we have designed and implemented the ``PolicySplitter'' tool,
 that transforms a given policy into small ones,
according to a chosen splitting criterion.
The obtained results have shown a significant gain in evaluation time when using any of the splitting criterion.
 The best gain in performance is reached by
the criterion that respects the synergy property. This plead in favor of a refactoring process that takes into
 account, the way PEPs are scattered inside the system business logic. 
In this work, we have easily identified the different PEPs since we know exactly how our system functions are
 implemented and thus how PEPs are organized inside the system.

As a future work, we propose to automatically identify the different PEPs of a given application. 
This technique is an important step that is complementary to this paper approach, since it enables
 knowing how PEPs are organized in the system and thus allows to select the most 
suitable splitting criterion for a given application. 


% An example of a floating figure using the graphicx package.
% Note that \label must occur AFTER (or within) \caption.
% For figures, \caption should occur after the \includegraphics.
% Note that IEEEtran v1.7 and later has special internal code that
% is designed to preserve the operationof this work  of \label within \caption
% even when the captionsoff option is in effect. However, because
% of issues like this, it may be the safest practice to put all your
% \label just after \caption rather than within \caption{}.
%
% Reminder: the "draftcls" or "draftclsnofoot", not "draft", class
% option should be used if it is desired that the figures are to be
% displayed while in draft mode.
%
%\begin{figure}[!t]
%\centering
%\includegraphics[width=2.5in]{myfigure}
% where an .eps filename suffix will be assumed under latex, 
% and a .pdf suffix will be assumed for pdflatex; or what has been declared
% via \DeclareGraphicsExtensions.
%\caption{Simulation Results}
%\label{fig_sim}
%\end{figure}

% Note that IEEE typically puts floats only at the top, even when this
% results in a large percentage of a column being occupied by floats.


% An example of a double column floating figure using two subfigures.
% (The subfig.sty package must be loaded for this to work.)
% The subfigure \label commands are set within each subfloat command, the
% \label for the overall figure must come after \caption.
% \hfil must be used as a separator to get equal spacing.
% The subfigure.sty package works much the same way, except \subfigure is
% used instead of \subfloat.
%
%\begin{figure*}[!t]
%\centerline{\subfloat[Case I]\includegraphics[width=2.5in]{subfigcase1}%
%\label{fig_first_case}}
%\hfil
%\subfloat[Case II]{\includegraphics[width=2.5in]{subfigcase2}%
%\label{fig_second_case}}}
%\caption{Simulation results}
%\label{fig_sim}
%\end{figure*}
%
% Note that often IEEE papers with subfigures do not employ subfigure
% captions (using the optional argument to \subfloat), but instead will
% reference/describe all of them (a), (b), etc., within the main caption.


% An example of a floating table. Note that, for IEEE style tables, the 
% \caption command should come BEFORE the table. Table text will default to
% \footnotesize as IEEE normally uses this smaller font for tables.
% The \label must come after \caption as always.
%
%\begin{table}[!t]
%% increase table row spacing, adjust to taste
%\renewcommand{\arraystretch}{1.3}
% if using array.sty, it might be a good idea to tweak the value of
% \extrarowheight as needed to properly center the text within the cells
%\caption{An Example of a Table}
%\label{table_example}
%\centering
%% Some packages, such as MDW tools, offer better commands for making tables
%% than the plain LaTeX2e tabular which is used here.
%\begin{tabular}{|c||c|}
%\hline
%One & Two\\
%\hline
%Three & Four\\
%\hline
%\end{tabular}
%\end{table}


% Note that IEEE does not put floats in the very first column - or typically
% anywhere on the first page for that matter. Also, in-text middle ("here")
% positioning is not used. Most IEEE journals/conferences use top floats
% exclusively. Note that, LaTeX2e, unlike IEEE journals/conferences, places
% footnotes above bottom floats. This can be corrected via the \fnbelowfloat
% command of the stfloats package.




% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://www.ctan.org/tex-archive/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
%\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)



% An example of a floating figure using the graphicx package.
% Note that \label must occur AFTER (or within) \caption.
% For figures, \caption should occur after the \includegraphics.
% Note that IEEEtran v1.7 and later has special internal code that
% is designed to preserve the operationof this work  of \label within \caption
% even when the captionsoff option is in effect. However, because
% of issues like this, it may be the safest practice to put all your
% \label just after \caption rather than within \caption{}.
%
% Reminder: the "draftcls" or "draftclsnofoot", not "draft", class
% option should be used if it is desired that the figures are to be
% displayed while in draft mode.
%
%\begin{figure}[!t]
%\centering
%\includegraphics[width=2.5in]{myfigure}
% where an .eps filename suffix will be assumed under latex, 
% and a .pdf suffix will be assumed for pdflatex; or what has been declared
% via \DeclareGraphicsExtensions.
%\caption{Simulation Results}
%\label{fig_sim}
%\end{figure}

% Note that IEEE typically puts floats only at the top, even when this
% results in a large percentage of a column being occupied by floats.


% An example of a double column floating figure using two subfigures.
% (The subfig.sty package must be loaded for this to work.)
% The subfigure \label commands are set within each subfloat command, the
% \label for the overall figure must come after \caption.
% \hfil must be used as a separator to get equal spacing.
% The subfigure.sty package works much the same way, except \subfigure is
% used instead of \subfloat.
%
%\begin{figure*}[!t]
%\centerline{\subfloat[Case I]\includegraphics[width=2.5in]{subfigcase1}%
%\label{fig_first_case}}
%\hfil
%\subfloat[Case II]{\includegraphics[width=2.5in]{subfigcase2}%
%\label{fig_second_case}}}
%\caption{Simulation results}
%\label{fig_sim}
%\end{figure*}
%
% Note that often IEEE papers with subfigures do not employ subfigure
% captions (using the optional argument to \subfloat), but instead will
% reference/describe all of them (a), (b), etc., within the main caption.


% An example of a floating table. Note that, for IEEE style tables, the 
% \caption command should come BEFORE the table. Table text will default to
% \footnotesize as IEEE normally uses this smaller font for tables.
% The \label must come after \caption as always.
%
%\begin{table}[!t]
%% increase table row spacing, adjust to taste
%\renewcommand{\arraystretch}{1.3}
% if using array.sty, it might be a good idea to tweak the value of
% \extrarowheight as needed to properly center the text within the cells
%\caption{An Example of a Table}
%\label{table_example}
%\centering
%% Some packages, such as MDW tools, offer better commands for making tables
%% than the plain LaTeX2e tabular which is used here.
%\begin{tabular}{|c||c|}
%\hline
%One & Two\\
%\hline
%Three & Four\\
%\hline
%\end{tabular}
%\end{table}


% Note that IEEE does not put floats in the very first column - or typically
% anywhere on the first page for that matter. Also, in-text middle ("here")
% positioning is not used. Most IEEE journals/conferences use top floats
% exclusively. Note that, LaTeX2e, unlike IEEE journals/conferences, places
% footnotes above bottom floats. This can be corrected via the \fnbelowfloat
% command of the stfloats package.




% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://www.ctan.org/tex-archive/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
%\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)
\begin{thebibliography}{1}
\bibitem{policymanagement}
P.Bouquet and H.Halpin and
               H.Stoermer and
               G.Tummarello,
  \emph{Entity Lifecycle Management for OKKAM},
 \hskip 1em plus   0.5em minus 0.4em
               Identity and Reference on the Semantic Web, \relax  Proceedings of the 1st IRSW2008 International Workshop on Tenerife, Spain,
               June 2, 2008.

\bibitem{acp}
P.Samarati and S.D.Capitani di Vimercati,
  \emph{Access Control: Policies, Models, and Mechanisms},
 \hskip 1em plus   0.5em minus 0.4em FOSAD, \relax  2000, 137-196.

\bibitem{Xengine}
Alex X. Liu and
               Fei Chen and
               JeeHyun Hwang and
               Tao Xie,
  \emph{Xengine: a fast and scalable XACML policy evaluation engine},
 \hskip 1em plus   0.5em minus 0.4em SIGMETRICS, \relax  2008, 265-276.


\bibitem{scalabilityaccesscontrol}
Angelos D. Keromytis and Jonathan M. Smith,
  \emph{Requirements for scalable access control and security management architectures},
 \hskip 1em plus   0.5em minus 0.4em THE ACM TRANSACTIONS ON INTERNET TECHNOLOGY (TOIT), \relax  2007.


\bibitem{separation}
 R. Yavatkar and D. Pendarakis and R. Guerin,
  \emph{A Framework for Policy-based Admission Control},
 \hskip 1em plus   0.5em minus 0.4em RFC Editor, \relax  United States, 2000.


\bibitem{oasis}
eXtensible Access Control Markup Language (XACML) Version 1.0,
http://www.oasis-open.org/committees/download.php/2406/oasis-xacml-1.0.pdf, 2003.

\bibitem{legacy}
Yves Le Traon and
               Tejeddine Mouelhi and
               Alexander Pretschner and
               Benoit Baudry,
  \emph{Test-Driven Assessment of Access Control in Legacy Applications},
 \hskip 1em plus   0.5em minus 0.4em
               ICST, \relax  2008, 238-247.

\bibitem{testcase}
T.Mouelhi and 
Y.Le Traon and            
               B.Baudry,
  \emph{Transforming and Selecting Functional Test Cases for Security
               Policy Testing},
 \hskip 1em plus   0.5em minus 0.4em
                ICST, \relax  2009, 171-180.


\bibitem{clustering}
M.Said and S.Mohamed and S.Anna and S.Smitha,
  \emph{Statistics \& clustering based framework for efficient XACML policy evaluation},
 \hskip 1em plus   0.5em minus 0.4em
              \relax  POLICY'09, London, United Kingdom,
               2009, 118-125.



\bibitem{decomposition}
Lin, Dan and Rao, Prathima and Bertino, Elisa and Li, Ninghui and Lobo, Jorge,
  \emph{Policy decomposition for collaborative access control},
 \hskip 1em plus   0.5em minus 0.4em
 \relax  SACMAT '08, USA, 2008, 103-112.



\bibitem{XACMLstructure}
P.Miseldine,
  \emph{Automated xacml policy reconfiguration for evaluation optimisation},
 \hskip 1em plus   0.5em minus 0.4em
               SESS,
 \relax  2008, 1-8.

\bibitem{models}
T.Mouelhi and
               F.Fleurey and
               B.Baudry and
               Y.Le Traon,
  \emph{A Model-Based Framework for Security Policy Specification,
               Deployment and Testing},
 \hskip 1em plus   0.5em minus 0.4em
 \relax  MoDELS, 2008, 537-552.

\bibitem{splitter}
PolicySplitter Tool, http://www.mouelhi.com/policysplitter.html, 2011.



\bibitem{sunxacml}
Sun$^\prime$s XACML implementation.
http://sunxacml.sourceforge.net/, 2005.

\bibitem{request}
E. Martin, T. Xie, and T. Yu,
 \emph{ Defining and measuring
policy coverage in testing access control policies},

 \hskip 1em plus   0.5em minus 0.4em
               ICICS,
 \relax  pages 139-158,
2006.


\bibitem{transforming}
T.Mouelhi and Y.Le Traon and B.Baudry,
 \emph {Transforming and Selecting Functional Test Cases for Security Policy Testing},
 \hskip 1em plus   0.5em minus 0.4em
               ICST,
 \relax  pages 171-180,
2009.

\end{thebibliography}
\end{document}


